This invention relates to computer operating systems. More specifically, it relates to a method and system for dynamic injection of dynamic link libraries into processes in a windowed operating system.
Software applications, such as 32-bit applications (e.g., Win32) for windowed operating systems, such as Windows 95/98, by Microsoft Corporation of Redmond, Washington, execute as separate processes that execute within their own address space. The Windows 95/98/NT operation systems limit code that can execute within an address space to the code associated with a main executable module (e.g., xe2x80x9c.EXExe2x80x9d) and Dynamic Link Library (xe2x80x9cDLLxe2x80x9d) modules loaded by a process associated with the main executable module. As is known in the art, a Dynamic Link Library provides a mechanism for linking applications to libraries of functions at run-time.
However, there are many situations where additional functionality needs to be added to a process by injecting execution logic into an address space. In particular, there are situations where it is desirable to inject execution logic into new address spaces that will execute before any application-related code executes. For example, applications to monitor or alter the execution of other applications need such additional functionality.
There are a number of techniques known in the art to inject execution logic into an existing windowed operating system""s process. However, these techniques have a number of associated problems. Three of these injection techniques include Dynamic Link Library injection, code patching, and remote threads. The Dynamic Link Library injection technique involves loading a Windows 95/98/NT Dynamic Link Library into an address space and placing injection code within a xe2x80x9cDllMainxe2x80x9d function. A Dynamic Link Library""s DllMain function is called by the Windows 95/98/NT operating system when a process loads or unloads a Dynamic Link Library as well as when a new operating system thread is started or stopped within a process. Thus, loading a Dynamic Link Library into an address space will result in the injected code""s execution within an address space. However, the injected code will only be executed after the process begins executing.
As is known in the art, there are two ways to inject a Dynamic Link Library into a Windows 95/98 address space including using an operating system registry key xe2x80x9cAppInit_DLLsxe2x80x9d or calling a xe2x80x9cSetWindowsHookExxe2x80x9d API function. As is known in the art, an operating system registry stores hardware, software and user configuration settings for particular a computer.
The AppInit_DLLs registry value can be used with Windows NT but is not implemented by Windows 95/98. A data value for the AppInit_DLLs registry value can contain a list of Dynamic Link Library module file names. When the Windows NT operating system module User Dynamic Link Library (e.g., USER32.DLL) is loaded into an address space, the user Dynamic Link Library will attempt to load the modules listed in this registry setting into a process address space. Use of the AppInit_DLLs registry value will only inject a Dynamic Link Library in a process that executes code within a user""s Dynamic Link Library (e.g., USER32.DLL).
However, both Windows 95/98 and Windows NT implement a SetWindowsHookEx Application Programmer""s Interface (xe2x80x9cAPIxe2x80x9d) function. This function is used to hook events within a primary operating system thread or for other operating system threads. When SetWindowsHookEx events occur, a callback function within a Dynamic Link Library is called by the Windows 95/98/NT operating system. If the hooked thread belongs to a different process than the calling thread, Windows 95/98/NT loads the required Dynamic Link Library into the hooked operating system thread""s address space. This Dynamic Link Library injection will only be invoked after an application associated with a process has started executing.
Code patching techniques known in the art require an injecting process having access to a target process. First the injected code is copied to a memory area in the target process address space. Next the target process is altered so that the injected logic will be executed. Finally, code within an existing execution thread is altered to execute the injected code. This is typically accomplished by calling injected code within an existing process execution path. Code patching is designed to work only on specific processes modified by a user.
The remote thread technique also requires an injecting process having access to a target thread. The injected code is copied to a memory area in the target thread address space. Then a new thread is started for the target process. This new thread executes the injected code. The remote thread technique also works only on specific processes modified by a user.
These injection techniques do not provide the ability for injected code to be the first non-operating system code to execute in new address space for a new process created by a windowed operating system. In addition these injection techniques are designed to work on specific processes modified by a user and do not allow injection techniques that are generally applicable to any process created by a windowed operating system.
In addition, while the injection techniques described above will inject a dynamic link library into an address space there are still a number of problems associated with the injection techniques. One problem is that these techniques do not work under Windows 95/98 and Windows NT. Another problem is that these techniques do not work without debugging functions. A process can only be xe2x80x9cdebuggedxe2x80x9d by one other process. Using the debugging functions to inject a module prevents a debugging application from being able to work properly.
Another problem is that these techniques do not work with minimal overhead. Injection logic should not force unnecessary overhead such as processing unneeded hook or debugging events. Another problem is that these techniques are not the first non-operating system code to execute within an address space. These techniques allow some application specific code to execute before logic within the injected dynamic link library is invoked. Another problem is that these techniques cannot be used to load injection logic into every new address space created for a process or to load different dynamic link libraries into different address spaces.
Another problem is that these techniques do not have the ability not to load a dynamic link library into an address space if is not needed or prevent loading undesirable dynamic link libraries.
Another problem is that these techniques do not have the ability to log dynamic link libraries that were injected into an address space or to inject the same dynamic link libraries into every new process as were injected into a process that creates a new process. This is called xe2x80x9ccascade loading.xe2x80x9d
In accordance with preferred embodiments of the present invention, some of the problems associated with injecting dynamic link libraries in a windowed operating system are overcome. Methods and system for dynamically injecting dynamic link libraries into a process in a windowed operating system is provided.
One aspect of the present invention includes a method for dynamically injecting dynamic link libraries into a process on a windowed operating system. The method includes executing injection logic from a process on the windowed operating system. The injection logic was injected into the process with an injection dynamic link library. An injection driver loaded by the injection application is queried from the injection logic. A test is conducted to determine from the injection driver whether any dynamic link libraries should be injected into a memory space created by the windowed operating system for the process. If any dynamic link libraries should be injected into the memory space for the process, an injection dynamic link library is loaded to inject the dynamic link libraries into the memory space for the process on the windowed operating system.
Another aspect of the present invention includes a method for determining which dynamic link libraries should be injected into a process on a windowed operating system. Another aspect of the invention includes a method for dynamically selecting dynamic link libraries. Another aspect of the invention includes a dynamic link library injection system comprising an injection driver and an injection dynamic link library.
The methods and system of preferred embodiments of the present invention may allow specific dynamic link libraries to be loaded into specific address spaces for processes created in windowed operating systems. The dynamic link libraries are loaded prior to the execution of any application related code in a process address space created by a windowed operating system.
The foregoing and other features and advantages of an illustrative embodiment of the present invention will be more readily apparent from the following detailed description, which proceeds with references to the accompanying drawings.